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Form PCT/lPEA/409 (Cover Sheet) (January 2004) 



INTERNATIONAL PRELIMINARY 
EXAMINATION REPORT 



International application No. PCT/EP 03/14978 



I. Basis of the report 
1. 



With reqard to the elements of the international application (Replacement sheets which have been furn shedto 
the Slna Office in response to an invitation under Article 14 are referred to ,n this report as ynginally filed 
and^e not ^eVed to thL report since they do not contain amendments Rules 70. 16 and 70. 1 7)): 



Description, Pages 

1-29 



as originally filed 



Claims, Numbers 

1-29 



received on 30.09.2005 with letter of 29.09.2005 



Drawings, Sheets 

1^-3/3 



as originally filed 



p With reaard to the language, all the elements marked above were available or furnished to this Authority in the 
KuS^ in which SSK?n4tional application was filed, unless oXhem\se indicated under this item. 

These elements were available or furnished to this Authority in the following language: . which is: 

□ the language of a translation furnished for the purposes of the international search (under Rule 23.1 (b)). 

□ the language of publication of the intemational application (under Rule 48.3(b)). 

□ the language of a translation furnished for the purposes of international preliminary examination (under 
Rule 55.2 andtor 56.3). 

3 With reaard to any nucleotide andibr amino acid sequence disclosed in the international application, the 
international preliminary examination was carried out on the basis of the sequence listing: 

□ contained in the intemational application in written fonm. 

□ filed together with the intemational application In computer readable form. 

□ fumished subsequently to this Authority in written form, 

□ fumished subsequently to this Authority in computer readable form. 

□ The statement that the subsequently furnished written sequence listing does not go beyond the disclosure 
in the intemational application as filed has been furnished. 

□ The statement that the information recorded in computer readable forni is identical to the written sequence 
listing has been furnished. 

4. The amendments have resulted in the cancellation of: 



□ the description. 

□ the claims, 

□ the drawings, 



pages: 

Nos.: 

sheets: 
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5. □ This report has been established as if (some of) the amendments had not been made, since they have 

been considered to go beyond the disclosure as filed (Rule 70.2(c)). 

(Any replacement sheet containing such amendments must be referred to under item 1 and annexed to this 
report,) 

6. Additional observations, if necessary: 

IV. Lack of unity of invention 

1 . In response to the invitation to restrict or pay additional fees, the applicant has: 

□ restricted the claims. 

□ paid additional fees. 

□ paid additional fees under protest. 

IS neither restricted nor paid additional fees. 

2. □ This Authority found that the requirement of unity of invention is not complied with and chose,.according to 

Rule 68.1 , not to invite the applicant to restrict or pay additional fees. 

3. This Authority considers that the requirement of unity of invention in accordance with Rules 13.1, 13.2 and 13.3 
is 

□ complied with. 

M not complied with for the following reasons: 
see separate sheet 

4. Consequently, the following parts of the intemational application were the subject of international preliminary 
examination in establishing this report: 

□ all parts. 

IS the parts relating to claims Nos. 1 -3,17-20 . 

V. Reasoned statement under Article 35(2) with regard to novelty, inventive step or industrial applicability; 
citations and explanations supporting such statement 



1. Statement 



Novelty (N) 



Yes: 
No: 



Claims 
Claims 



1-3,17-20 



Inventive step (IS) 



Yes: 
No: 



Claims 
Claims 



1-3,17-20 



Industrial applicability (lA) 



Yes: 
No: 



Claims 
Claims 



1-3,17-20 



2. Citations and explanations 
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Be Item IV 

Lack of unity of invention 

1 . This International Examining Autliority found multiple inventions in this 
international application, as follows: 

(I) Independent claims 1 , 17, 21 (part) are directed to secure user authentication in a 
telecommunication core network. This is achieved by an authentication gateway, a 
user* equipment, means for and steps of carrying out an authentication procedure; 
computing a secret user's key; deriving, storing and confimning user's shared keys, 
sending the user's shared key along with the user's identifier. 

* 

(II) Independent claims 4 and 21 (part) are directed to management of master session 
records for registered users. This is achieved by a session manager, means for and 
steps of receiving user's shared keys and user's identifiers, creating a master 
session, checking whether user's shared key matches the shared key in user's 
master session. 

(III) Independent claim 8 is directed to access control to sen/ices during active sessions. 
This is achieved by a service access authentication node, means for and steps of 
verifying whether an active session is indicated, assessing that user's shared keys 
are stored, determining a key match, granting access to the requested sen/ice. 

2. Sending and receiving user's shared keys is common general knowledge, which 
is, e.g., known from the exchange of symmetric content encryption/decryption 
keys between content owner and content user In data networks. 

3. Consequently, neither the objective problems underiying the subjects of the three 
claimed inventions, nor the solutions as defined by the special technical features 
described allow for the link of a common inventive concept .to be established 
between said inventions. In conclusion, the three groups of claims are not linked 
by a single general inventive concept. The application hence does not meet the 
requirements of unity of invention as defined in Rules 13.1 .and 13.2 PCT. : 
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Pfi Item V 

Reasoned statement with regard to novelty, inventive step or. industrial applicability; 
citations and explanations supporting such statement 

1 The following documents are referred to in this communication; the numbering will be 
adhered to in the rest of the procedure: 

D1 : 3GPP TS 33.234 "Wireless Local Area Network (WLAN) Interworking Security", 
XP002282973 

D2: "SECURE AUTHENTICATION SYSTEM FOR PUBLIC WLAN ROAMING", 
XP001 046692 

2. Claim 1 does not fulfil the requirements of Article 33(1 ) PCT, because its subject- 
matter is not inventive, Article 33(3) PCT. 

2.1 . D1 discloses according to most of the features of apparatus claim 1 (the references 
in parentheses applying to D1): 

an authentication gateway ("3GPP AAA server", page 11, line 21 and Fig. 4.3) 
arranged for receiving an access request in a telecommunication core network from 
an entity in an access network where a user with a user's equipment accesses 
through, the user being subscriber of the telecommunication core network and being 
identified by a user's identifier included in the access request. the authentication 
gateway having: 

means for carrying out an authentication procedure with the user's equipment 
through the access network in order to authenticate the user (page 1 1 , lines 22- 

24). 

means for computing at least one secret user's key ("EAP-SIM derived key", 
page 23, lines 39) usable as cryptographic material, 

means for deriving from the cryptographic material a user's shared key (page 
23, lines 34, 39-40). 

2.2. The subject-matter of claim 1 differs from the disclosure in D1 in means for sending 
for SSO authentication purposes the user's shared key along with the user's 
identifier. 
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2.3. The objective technical problem is subsequent authentication of an authenticated 
user without further user interaction. 



2.4. Means for sending for SSO authentication purposes the user's shared key along with 
the user's identifier is a corDmon measure, which Is, e.g., known from fonwarding 
RADIUS authentication messages to the home provider when roaming across 
different providers, which is disclosed in D2. page 115, left-handed column, lines 10- 
1 3. Taking this meaure is supported by the hint in D1 to support trust between.two 
different providers/operators based on a roaming agreement or Single-Sign-On 
solutions, see page 43, lines 24-28 and Fig. B.I) 

It should be mentioned that the broad terni. "service network" may be Interpreted to 
comprise any wireless access network, cellular operator's network or application layer 
service network like a WAP infrastructure. 

3. Independent claim 17 does not fulfil the requirements of Article 33(1) PCT; because 
its subject-matter is not inventive. Article 33(3) PCT. > 

3.1 . Most of the features of apparatus claim 1 7 correspond to the features of apparatus 
claim 1 , and, in addition, claim 1 7 mentions a user's equipment, means for confirming 
the user's shared key and a repository for storing the keys, which Is also known from 
D1 (Fig. 7.2.; page 24, lines5-8; page 1 1, line 4). 

4. The additional features of the dependent claims do not add anything inventive to the 
independent claims because the features are either known from the above cited prior 
art (processing key to obtain a key code MAC) or are common measures (notification 
about established or temninated session at access level, means for downloading a . 
plug-in, receiving a SSO cookie). 
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CLAIMS 

. 1 . An Authentication Gateway (AG) arranged for receiving (S- 
23) an access request in a telecommunication core network 
(CN) from an entity (WLAN-AS) in an access network (WIiT^) 
5 where a user with a user's equipment (UE) accesses 

through, the - user heing subscriber of the 
telecommunication core network (CKT) and being identified 
by a user's identifier included in the access request, 
the Authentication Gateway having: 

10 - means for carrying out (S-25) an authentication 

procedure (SIM-based; AKA; EAP) with the user's 
equipment (UE) thrdugh the access network (WLAN) in 
order "tfo authen'ETcate theHuser; 

- means for computing at least one secret user's key 
15 (Kc) usable as cryptographic material; and 

- means for deriving (S-251) from the cryptographic 

4 

material (Kc.) a user's shared key (SSO_key-l) ; 
and characterised by comprising: 

« 

- means for sending (S-30) for SSO authentication 
20 ' . purposes the user's shared key (SSO_key-l) along with 

the user'^s identifier towards a session manager 
(SSO_SM) serving a service network (SN) . 

2. The Authentication Gateway of claim 1, further comprising 
means for being notified (S-29) that a session at the' 

25 access level has been established, this notification 

triggering the sending (S-30) of the user's shared key 
(SSO_key-l) towards the session manager (SSO_SM) serving 
the service network (SN) . 

3. The Authentication Gateway of claim 2, further comprising 
3D means for being notified that a session at the access 

AMENDED SHEET ^BSS 



level has been terminated (accoxinting stop message), and 
means for forwarding this notification towards the 
session manager (SSO_SM) serving the service network (SN) 
in order to inactivate a current master session for the 
user. 

A session manager (SSO_SM) serving a service network (SN) 
for SSO purposes and arranged for managing a session 
record for a user accessing the service network (SN) 
through an access network (WLAN) , the user having been 
authenticated by a telecommunication core network (CN) 
where the user holds a subscription, the session manager 
(SSO_SM) characterised in that comprises: 

— means for receiving (S-30) a first user's shared key 
'("SSO_key^) and a user's identifier from an 

Authentication Gateway (AG) of the core network (CN) 
for SSO authentication purposes, this first user's 
shared key (SSO key--l) obtainable during ' the 
authentication of the user by the core .network (CN) ; 

— means for creating (S-301) a master session for the 
user that comprises the user's .identifier and the 

. received first user's shared k:ey (SSO_Jcey-l> , ' arxd 

— means for checking (S-34) whether a second user's 
shared key (SSO_key-2) derived at the user ' s . equipment 

' (UE) and received from a service access authentication 
node (SAAN) * of the service . network (SN) matches the 
first user's shared key (SSO_key-l) included in the 
master session for the user. 

The session manager of claim 4, further including means 
for creating a service session to index the master 
session, in case of matching first and second user's 
shared keys, this service session intended as a token of 
a successful SSO user authentication. 
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■ 

The session manageir of claim 5, further including neans 
for verifying whether a service session indexes an active 
master session for a user to determine if a previous SSO 
authentication is still valid. 

The session manager of claim 4, wherein the means for 
checking (S-34) , whether a second user's shared key 
(SSO_key-2) derived at the user''s equipment (UE) matcdies 
the first- user's shared key (SSO_key-l) included in the 
master session, comprises means for processing the first 
user's shared key (SSO_key-l) to obtain a first key code 
(MAC{SSO_key-l) ) to be matched against a second key code 
(MAC(SSO_key-2) ) originated from the user's equipment, 

A service access authentication node (SAAN) intended for 
receiving, rs-31) ^ a request from a user"^' accessing" a" 
telecommunication service network (SN) through an access 
network (WLiAN) with a user's equipment (UE) , the user 
already authenticated by a telecommunication core network 
{C3jJ) where the user holds a sxibscription, the request 
including a , user's identifier to identify the user, the 
service access authentication node characterised by 
comprising: 

- means for verifying whether an active service session 
is indicated in the request from the user's equipment; 

- means for obtaining (S-33) a user's shared key 
(SSO_key-2) derived at the user's equipment (UB) and 
stored therein; and 

- means for determining (S-34) in cooperation with a 
session manager (SSO_SM) serving the service network 
(SN) for SSO purposes whether the user's shared key 
(SSO_key--2) at the user's equipment (UE) matches the 
one stored in the master session (SSO_key-l) for the 
user . 
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• ■ 

The service access authentication node (SAAN)of claim 8^ 
further comprising means for obtaining a service session 
for a user from the session manager (SSO_SM) serving the 
seirvice network (SN) for SSO purposes. 

The service access authentication node f SAAN) of claim 9, 

* 

further including means for generating an SSO cookie to 

• « 

be submitted (S-37) to the user's equipment (UE) , the SSO 
cookie comprising the service session. 

The service access authentication node (SAAN) of claim 10, 
further comprising means for receiving an SSO cookie from 

■ 

the user's equipment (UE) , the SSO cookie indicating a 
service session for the user. 

The -service- access -authentication node. tSAAN->of- claim, 
further comprising means for downloading an SSO plug-in 
towards the user's equipment, the SSO plug-in running for 
confirming back the user's shared key {SSO_key-2).. 

The service access authentication node (SAAN) of claim 8, 
wherein the means for obtaining (S-33) a user's shared 
key {SSO__key-2) derived at the 'user's equipment (UE) 
includes means for receiving from the user's equipment an 
element selected from: 

- a key code (MAC(SSO_key-2) ) obtainable by processing 
the user's shared key (SSO_key-2) at the user's 
equipment ; and 

» 

— the user's shared key {SSO_key-2) . 

The service access authentication node (SAAN) of claim 13, 
further comprising means for siibmitting the received 
element to a cooperating session manager (SSO_SM) serving 
the service network (SN) for SSO puirposes. 

A use of the service access authentication node (SAAN) of 
claim 8 as an HTTP Proxy receiving service . recjuests (S- 
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31) from users accessing a service network (SN) in a 
Walled -Garden SSO model. 

16. A use of the service access authentication node (SAAN) of 
claim 8 as an authentication node of an Identity Provider 
where a credential request (S-31) is received from a user 
accessing a service of a Service Provider (SP) in a 
Federated SSO model. 

17. A user's equipment (UE) usable by a user with a 
sxibscription in a telecommunication network, and arranged 
to access a telecommunication service network (SN) 
through an access network (WLAN) , the user' s equipment 
(UE) having: 

-means- for —carrying -out- iS-2B)- an a-utheatication 
procedure (SIM-based; AKA; EAP) to authenticate the 
user with a core network (CN) , where the user holds 
the subscription, through the access network (WLAN) ; 

- means for confuting at least one secret user's key 
(Kb) usable as cryptographic material; 

• ■ 

- means (S-252) for deriving from the cryptographic 
material (Kc) a user's shared key (SSO_key-2) ; and 

- a repository, for storing the user's shared key 
(SSO_key-2) ; 

* 

and characterised by comprising: 

- means for conf inning (S-32, S-33) for SSO 
authentication purposes the user's shared key 
(SSO_key-2) derived at the user's equipment towards an 
entity (SAAN, SSO_SM) in the service network (SN) . 

.8. The user's equipment of claim 17, wherein the means for 
confirming (S-32, S-33) includes means for downloading an 
SSO plug- in from an entity (SAAN, SSO SM) in the service 
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network (SN) , the SSQ plug- in running for confirming back 
• the user's shared key. 

4 

. The user's equipment of claim 17, wherein the means for 
confirming (S-32, S-33) includes means for processing the 
user's shared key (SSO_key-2) to obtain a key code 
. (MAC (SSO_key-2) ) to be transmitted to an entity (SAAN, 
SSO^SM) in the service network (SN) • 

. The user's equipment of claim 17, fi^rther comprising 
means for receiving an SSO cookie from an entity (SAAN, 
SSO SM) in the service network, the SSO cookie to be 
included in all further service requests from the user's 
equipment as an SSO token. 

A. me.tho.d f or:..suppoxt.ing Singie Sign-On sejrvices. _f or a 

user with a user's equipment (UE) arranged for accessing 
a telecommunication core network (CN) and service network 

* 

(SN) through an access network (WLAN) , the user being 
identified as stibscriber of the telecommunication . core 
network (C3iJ) when acces^sing the access network (WIiAN) , 
the method comprising the steps of : 

- carrying out (S-25) an authentication procedure for 
the user between an entity (AG, HLR) of the core 
network (CN) and the user's equipment (UE) 

■ 

« 

« 

- computing at the entity (HIjR, AG) of the core network 
(CN) at least one secret user's key (Kc) usable as 
cryptographic material; 

- computing at the user's equipment (UE) at least one 
secret user's key (Kc) usable as cz-yptographic 
material ; 

- deriving (S-251)- a first user's key (SSO_key-l) from 
the cryptographic material at the entity (AG) of the 
core network (CN) ; and 
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t 

deriving (S-252) a second user's key {SS0_key-2) from 
the cryptographic material at the user's equipment 
(XJE) ; 

and characterised by including the steps of : 

5 — creating (S-301) a master session for the user at an 

entity (SAAN, SSp_SM) in the service network, the 
master session comprising a user's identifier and the 
first user's key (SSO_key-l) usable for SSO 
authentication purposes; 

■ ■ 

10 - confirming (S-32, S«33) for SSO authentication 

purposes the second user's shared key (SSO_key-2) 
derived at the user's^ equipment towards the entity 
(SAftN, &SO_SM) in the service network (SN) ; 

- verifying (S-34) whether the second user's shared key 
15 (SSO_key-2) matches the first user's shared key 

(SSO_key-l) for the user at the Entity (SAAN, SSO_SM) 
in the service network (SN) ; and 

- granting (S-35, S-36, S-37) access to the requested 
service in the service network (SN) on matching the 

20 first and second user's shared keys. 

22. The method of claim 21, wherein the step of verifying (S- 
34) the matching of the first and second user's shared 
keys further includes a step of creating a service 
session to index the master session, this service session 

25 intended as a token of a successful SSO authentication, 

23. The method of claim 22, further including a step of 
generating an SSO cookie to be submitted to the user's 
equipment, the SSO cookie comprising the service session. 
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24. The method of claim 23, further comprising a • step of 
verifying whether an active service session is indicated 
in the rec[uest from the user' s . equipment . 

25. The method of claim 21, wherein the step of confirniting 
5 (S-32, S-33) for SSO authentication purposes the second' 

^ 

user's shared key (SSO_key-2) derived at the user's 
equipment, includes a step of downloading an SSN plug- in 
from an entity (SAAN, SSO_SM) in the service network 
(SN) , the SSO plug- in running for confirming, back the 
10 user's shared key (SSO_key-2) , 

26. The method of claim 21, wherein the step of confiriBDing 
(S-32, S-33) for SSO authentication purposes the second 
user's . shared key (SSO_key-2) stored at the user's 

equipment r --inc-ludes ra step- - o€-' processing -^he * u:s*er"'"'S' . 

15 shared key (SS0_key-2) to obtain a key code {iyiAC(SSO_key- 

2)) to be transmitted to an entity (SAAN, SSO_SM) in the 
service network (SN) . 

27- The method of claim 26, wherein the step of verifying (S- 
34) whether the second user's shared key (SS0_key-2) 

20 matches the first user's shared key (SSO_key-l) includes 

a step of processing at an entity (SAAN, SSO_SM) of the 
service network (SN) the first user's shared key 
(SSO_key-l) to obtain a first key code (MAC {SSO_key-l) ) 
to be matched against a second key code (MAC (SSO key-2) ) 

25 originated from the user's equipment. 

28- The method of claim 21, wherein the step of creating (S- 
301) a master session for the user at the entity (SAAN/ 
SSO_SM) in the service network includes a step of 
receiving the first user's key (SSO_key-l) usable for SSO 

30 authentication purposes from an entity (AG) of the core 

network (CW) . 

29. The method of claim 21, wherein the step of creating (S- 
301) a master session for the user at the entity (SAAN, 
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SSO_SM) in the service network includes a step - of 
initiating an access session (S-29) when the user 
accesses the access network. 
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